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ABSTRACT 


This  paper  discusses  the  uses  of  the  MADAM  system  for  data 
management  tasks  on  the  small,  free-standing  computer  such 
as  the  IBM  1401  or  IBM  360/30.  It  is  largely  nontechnical  in 
approach  and  is  addressed  to  managers  rather  than  to  computer 
personnel.  An  exapple  of  a  problem  and  its  solution  is  given 
to  demonstrate  the  speed  and  simplicity  of  MADAM  usage. 
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Hov  Big  is  Small? 

Depending  upon  their  backgrounds,  people  are  likely  to  h&ve  different  defini¬ 
tions  of  what  constitutes  a  small  computer.  I  have  heard  one  expert  describe 
an  IBM  360  Model  50  with  128k  core  and  several  disc  packs  as  a  small  computer. 
Others  feel  that  anything  beyond  a  desk-side  engineering  computer  cannot  be 
classified  as  small.  With  this  wide  range  of  views  in  mind,  I  will  define 
the  small  computer,  for  purposes  of  this  paper,  as  the  smallest  on  which  it 
is  practicable  to  operate  a  data  management  system.  It  must  have  enough  high 
speed  memory  to  house  a  data  management  program  together  with  the  unit  records 
for  input  and  output.  It  rauot  have  sufficient  input/output  capability--at 
least  four  magnetic  storage  devices--to  perform  operations  of  Bortlng  and 
merging  which  are  essential  to  data  management.  The  instruction  set  must 
provide  arithmetic  and  logical  capability.  These  criteria  eliminate  many 
small  computers  which  are  not  practical  for  data  management  system  use. 
Nevertheless,  they  leave  within  the  defined  class  a  large  number  of  machine- 
representing  almost  every  significant  manufacturer.  A  good  example  of  the 
class  is  the  raedium-to-small  business  computer.  The  particular  data  management 
system  I  am  about  to  describe,  MADAM  (for  Moderately  Advanced  Data  Management), 
has  been  prepared  for  two  ouch  machines. 

It  might  be  instructive  to  consider  the  reasoning  behind  the  selection  of  the 
original  computer  for  which  the  MADAM  system  was  first  implemented.  This 
machine,  the  IBM  l4d,  has  the  following  minimum  features: 

Feature  Comment 

OK  of  memory  Less  than  OK  does  not  provide  adequate  storage 

for  management  programs  and  significant  data. 

Advanced  Programming  Indexing  and  high-low-equal  compare  make  possible 

Features  the  coding  of  generalized  management  programs 

compactly  and  efficiently. 

k  Tape  Units  This  is  the  minimum  for  accommodating  input  and 

output  files  and  a  system  master  tape  and  for 
efficient  file  sorting. 

What  Is  'Data  Management" ? 

In  the  B.C.  (Before  Computers)  era  the  functions  we  now  cal]  data  management 
consisted  of  keeping  books  and  maintaining  files  by  hand.  Books  had  to  be 
accurate  and  up  to  date.  Files  had  to  be  organized  so  that  information 
stored  in  them  could  be  retrieved  U3  needed.  New  information  had  to  be 
added  and  obsolete  information  n-nv.ed.  These  requirements  held  true  whether 
the  environment  was  business,  government,  academic  research  -a'  a  library. 

Today  nothing  has  changed  except  the  means  of  accomplishment .  Thus  a 
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computerised  data  management  system  la  one  vhleh  can  keep  accurate  and  timely 
records  and  can  build,  maintain  and  retrieve  information  from  files. 

Why  generalised  Systems? 

u«ery  organisation  has  its  own  methods  of  record  keeping,  its  own  set  of 
periodic  reports  and  its  own  requirements  for  file  organization.  Host  organ¬ 
isations  that  have  computerized  these  methods  have  written  or  procured 
computer  programs  tailored  to  their  needs.  Nobody  else  can  use  these 
programs.  Moreover,  the  particular  organisation  cannot  change  or  expand 
its  methods  without  writing  new  programs  or  modifying  old  ones.  The  writing 
of  programs  and  the  updating  of  existing  programs  is  extremely  expensive  and 
tends  to  inhibit  full  use  of  a  computer's  potential  by  an  organization. 
Fortunately,  however,  despite  the  individual  characteristics  of  each  orgsui- 
1 ^niton's  method  of  operation,  all  such  operat'ons,  considered  broadly, 
closely  resemble  one  another.  The  functions  wi  ich  are  performed  sure  few 
In  ninber  and  standard  in  application.  The  ft notions  themselves  are 
independent  of  data  content  and  of  data  format.  It  1b  possible,  therefore, 
produce  a  set  of  programs  that  contain  capabilities  for  the  standard 
functions  of  data  management.  All  that  is  required  is  to  specify  at  execution 
i ime  the  data  formats  involved  and  the  rules  for  decisions  which  must  be  made 
or.  the  basis  of  data  content.  Such  specifications  do  not  have  to  be  made  In 
tha  language  of  computers;  they  can  be  made  in  the  language  of  the  bookkeeper, 
a  file  clerk,  librarian,  or  data  aneilyst,  a  language  with  which  the  data 
handler  is  thoroughly  familiar  and  in  the  use  of  which  he  is  less  likely  to 
expensive  errors  than  is  a  programner  using  computer  code.  Such  program 
neirx  ure  possible  and  economic  pressure  has  resulted  in  many  efforts  to 
<  ii.a trust  them.  Most  such  efforts,  however,  are  designed  for  use  on  large 
■  :i,!'uterc.  The  user  who  has  most  economic  need  for  an  off-the-shelf  system, 
h  oraall  computer  user,  is  largely  neglected.  MADAM  is  an  attonpt  to 
.-x-j'jdy  that  neglect. 

a. -act eristics  of  the  MADAM  System 

/lit  MADAM  system  is  currently  available  on  the  IBM  l4ot.  series  machines  and 
t  ; o  IBM  360/30.  No  attempt  is  mode  in  this  paper  to  differentiate  between 
■: .c  two  versions  in  the  discussion  of  characteristics  sod  capabilities. 

.  ‘.-ailed  information  about  each  is  found  in  some  of  the  documents  listed 
the  bibliography. 

In  view  of  some  of  the  publicity  currently  surrounding  the  glamorous  data 
mnageraent  systems  being  built  for  large  computers,  it  would  be  useful  at 
the  start  to  make  some  disclaimers  for  MADAM,  to  state  what  it  is  not.  In 
the  first  place  it  is  not  an  on-line  system.  Inputs  go  in  and  outputs  are 
returned  via  the  computer  operating  console  area.  In  tne  second  place  it 
1  ;  not  a  symbolic  data  manipulator.  Data  elements  are  not,  as  in  most 
.-■yriems,  first  defined  and  named  and  then  referred  to  by  name.  As  far  as 
tne  first  restriction  is  concerned,  tne  designers  of  MADAM  feel  that  a  vast 
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amount  of  data  management  work  does  not  require  nor  Justify  the  expense  of 
am  on-line  system,  especially  in  a  Broall  installation.  In  the  second  matter, 
data  symbology  haws  been  sacrificed  for  efficiency.  It  is  the  capability  for 
defining  symbols  that  makes  bo  many  systems  too  large  for  the  small  machine 
and  which  makes  small-machine  assemblies  take  6even  or  more  pa».rcc  to  convert 
symbolic  program  code  to  machine  format.  MADAM  is  a  tr&nslate-and-go  system 
in  which  the  interval  between  translation  and  execution  is  scarcely  perceptible 
to  the  observing  layman. 

The  MADAM  system  consists  of  a  control  program  and  a  series  of  translator- 
interpreter  pairs  of  programs  which  are  called  in  response  to  the  various 
conmands  in  the  MADAM  language.  The  MADAM  system  resides  on  a  magnetic  tape, 
and  the  specifications  which  control  its  operation  are  entered  through  the 
card  reader  or  from  a  MADAM  library  tape.  MADAM  continues  to  operate, 
performing  one  set  of  specifications  at  a  time,  until  no  more  specifications 
are  left  to  execute.  It  is  usual  to  enter  a  number  of  such  sets  whose 
operation  constitute  a  complete  data  management  Job. 

User-Oriented  Language 

The  term  user-oriented  is  very  much  in  vogue,  and  is  claimed  to  apply  to  the 
control  language  of  most  systems  produced  today.  Not  all  users  are  alike, 
however,  and  a  language  oriented  to  a  so-to-speak,  least  common  denominator 
user  would  scarcely  be  satisfactory  to  the  majority  of  all  possible  users. 
User-oriented  must  be  understood  as  oriented  to  the  user  for  which  the  system 
is  intended.  Earlier  in  this  document  I  used  the  phrase  deta-handler,  and  I 
believe  this  tern  comes  as  close  as  possible  to  describing  the  user  for  whom 
the  MADAM  language  is  user-oriented.  This  user  is  not  someone  picked  casually 
off  the  street.  On  the  other  hand,  he  is  not  the  trained  professional,  the 
scientist,  the  engineer  or  the  senior  business  executive.  Such  people  may, 
and  indeed  do,  make  use  of  MADAM  from  time  to  time.  The  intended  user, 
however,  ir  the  one  who  has  dally  contact  with  the  data  managed  by  the  system, 
who  is  responsible  for  entering  data  into  the  systan  and  for  producing  the 
reports  generated  by  the  system.  Such  a  user  is  familiar  with  the  details 
of  data  format  and  data  content,  and  for  him  the  MADAM  language  gives  an 
easy-to-use,  rather  natural  method  of  controlling  the  computerized  data 
management  application.  This  person  is  seldom  the  ultimate  user  of  the 
system,  but  he  is  the  necessary  interface  between  those  who  need  the  output 
or  supply  the  input,  and  the  computerized  facility. 

Procedural  and  Mon- Procedural  Specifications 

MADAM  har.Hes  two  kinds  of  specifications  presented  to  it  in  the  MADAM 
language.  Procedural  specifications  are  those  in  which  the  system  is 
instructed  on  a  step-by-step  basis  how  to  process  the  data:  that  is,  when 
to  read,  what  to  transfer,  what  to  compute,  what  to  compare,  what  to  print 
and  so  forth.  With  this  type  of  specification  the  user  has  great  flexibility 
in  producing  formatted  reports,  in  selecting  or  merging  data  files  or  updating 
a  data  base. 
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The  second  hind  of  specification  is  called  non-procedural.  Here  the  operation 
is  standard  and  highly  automatic,  and  the  user  has  only  to  supply  a  few  param¬ 
eters  to  mahe  the  process  apply  to  the  particular  circumstances.  Ron- procedural 
specifications  include  the  provision  of  keys  for  file  sorting  and  the  rules  for 
copying,  combining  or  blocking  files. 

Data  Reference 


I  mentioned  before  that  MADAM  did  not  provide  for  the  predefinition  and 
symbolic  naming  of  data  elements.  Instead  data  is  referred  to  by  its  position 
in  the  data  record  image  or  storage  area.  A  datum  reference  is  thus,  directly, 
an  address  which  mentions  the  region  containing  the  datum,  the  starting  char¬ 
acter  of  the  datum  relative  to  that  region  and  the  number  of  characters  in 
the  datum.  This  16  a  very  natural  way  of  specifying  data  to  the  data-handler 
who  has  before  him  the  layout  of  the  file  or  the  format  of  a  report. 

Special  Features 

MADAM  possesses  several  capabilities  which  are  not  found  in  the  usual  small- 
scale  data  management  syr^em.  An  Indirect  addressing  capability  enables 
general  procedures  to  be  established  which  can  handle  several  different  data 
elements  or  which  can  be  used  to  control  the  formatting  of  variable  length 
strings.  There  is  the  ability  to  specify  general-purpose  subroutines  which 
can  be  called  from  different  parts  of  the  main  specification.  A  library 
capability  enables  often-used  specifications  to  be  stored  and  called  for 
execution  by  assigned  name.  The  library  function  also  permits  partial 
specifications  to  be  stored  and  assembled  dynamically  into  a  complete 
specification  at  execution  time.  Finally,  there  is  the  unusual  capability 
to  scan  variable  field  data  such  as  natural  language  text.  Word  separators 
can  be  defined  by  the  user  so  that  fields  which  are  retrieved  are  appropriate 
whether  the  data  is  language,  mathematical  expression  or  computer  code. 

MADAM  Applications 

The  following  pages  give  brief  accounts  of  some  of  the  problems  for  which 
MADAM  has  been  useful. 

1.  Data  Documentation 


A  set  of  MADAM  specifications  known  as  DATADOX  was  written  for  the  data 
managenent  effort  of  the  Bay  Area  Transportation  Study  Commission.  Very 
large  files  of  source  data  and  derived  data  from  questionnaires  and  other 
typ«s  of  survey  were  collected.  The  files  were  processed  by  a  large 
computer  data  managenent  system  called  SPAN.  The  DATADOX  specifications 
were  written  to  process  the  SPAN  specifications  and,  from  the  information 
contained  in  them,  generate  data  dictionaries  containing  cross-indexed 
references  to  data  elements,  data  lists,  files,  and  so  forth.  By  using 
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MADAM,  BATSC  analysts  were  able  to  solve  one  cf  the  severe  problems  of 
any  large-scale  study,  namely  the  accounting  <ind  documentation  requiremmts 
for  the  wide  range  of  statist!  cal  data  used  by  the  study. 

2.  Document  Retrieval 

The  SlTOF  =v«t»"  developed  at  CDC,  is  a  aeries  of  MADAM  specifications 
which  provide  the  individual  with  a  means  of  storing  information  about 
documents  of  interest  to  him,  including  such  things  as  personal  notes, 
letters  and  the  like,  traditionally  the  most  difficult  things  to  handle. 

The  system  operates  as  a  service  with  subscribers.  Subscribers  ore  able 
to  enter  new  data  at  intervals  and  jure  able  to  retrieve  lists  of  relevant 
documents  based  on  Inquiries  which  are  keyed  on  subject  matter  descriptors, 
author,  title,  date  and  so  forth.  While  this  is  not  so  spectacular  as  an 
on-line  retrieval  system,  the  fact  that  many  persona  share  in  the  use  of 
a  small  inexpensive  facility  makes  economically  possible  the  personal, 
as  opposed  to  the  library,  document  retrieval  Bysten. 

3.  File  Reformatting 

It  is  frequently  the  case  that  data  files  exist  in  one  format  when  the 
data  they  contain  is  required  in  an  entirely  different  format.  It  is 
uneconomical  and  often  impossible  to  collect  the  data  again.  MADAM  is 
frequently  used  at  SDC  to  reformat  data.  For  example,  a  Department  of 
Defense  file  containing  information  keypunchca  from  a  typical  report  form 
was  radically  altered  for  use  with  the  LUCID  system.  MADAM  was  used  to 
perform  this  task  and  without  MADAM's  text  scanning  ability  the  process 
might  have  been  too  expensive  to  be  worth  undertaking. 

4.  Tabulation 

MADAM  is  used  to  prepare  summary  reports  as  an  aid  to  management  at  SDC. 

It  has  also  been  used  to  produce  scattergrams  based  on  a  statistical 
matrix.  Because  of  limited  core  space  this  process,  performed  for  a 
national  professional  organization,  ran  very  slowly  on  the  machine.  In 
terms  of  total  throughput  time,  however,  it  was  probably  faster  than  it 
would  have  been  had  it  been  necessary  to  code  and  check  out  programs  for 
a  large  and  powerful  machine.  The  Job,  from  presentation  of  the  data  to 
finished  reports,  required  forty-eight  hours. 

The  applications  listed  above  are  Intended  to  show  the  wide  range  of  problems 
for  which  MADAM  may  be  used.  It  is  only  a  small  sampling  of  the  actual  uses 
that  have  been  made,  and,  or  course,  a  still  smaller  fraction  of  those  for 
which  the  system  is  potentially  usejul* 
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An  Example 

This  final  section  la  for  those  hardy  (and  interested)  enough  to  want  to  get 
the  actual  flavor  of  MADAM.  The  problem  chosen  is  simpler  than  it  would  be 
in  real  life.  It  does,  however,  give  an  adequate  view  of  how  problems  are 
attacked  with  MADAM  and  how  simple  and  succinct  the  MADAM  solution  often 
turns  out  to  be. 

The  problem  concerns  the  updating  of  on  inventory  file.  Three  separate  files 
uc  involved.  They  are: 

1.  Product  file— contains  the  product  number  and  the  unit  price  of  that 
product . 

2.  Inventory  file— contains  for  each  location  a  record  for  each  product 
number  on  hand,  together  with  the  number  of  units  and  the  total  value. 

3.  Transaction  file— this  is  a  daily  report  file  which  contains  a  record  for 
each  product  at  each  location  for  which  a  change  in  status  has  occurred. 

The  change  may  either  be  a  receipt  of  more  items  or  a  reduction  in  the 
number  of  items. 

The  requiranent  is  to  use  the  Transaction  File  to  update  the  Inventory  File, 
obtaining  the  unit  price  from  the  Product  File.  Describing  the  fields  in  the 
various  files,  the  start  1b  computed  from  zero.  That  is,  the  first  character 
position  of  the  record  is  position  zero,  the  second,  position  one  and  bo  forth. 
This  is  how  fields  are  referred  to  in  MADAM  and,  to  Keep  things  consistent, 
these  references  will  be  used  in  describing  the  records  of  the  various  files. 

The  Product  File 


In  real  life  this  file  would  have  many  more  fields,  such  as  cost  figures, 
blueprint  numbers,  patent  numbers,  Government  specification  numbere,  name  of 
product  and  so  forth.  For  present  purposes  we  predicate  a  file  with  only  two 
fields — product  code  number  and  unit  price.  Furthermore,  we  assume  that 
prices  are  in  even  dollars  to  avoid  the  complication  of  deeding  with  decimal 
points.  The  Inventory  File,  then,  consists  of  twenty  character  records.  Itoe 
field  0  through  5  contedns  the  product  code  number.  The  field  7  through  10 
contains  the  unit  price.  The  file  is  in  product  code  number  order. 
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PRODUCT  FILE 

Positions 

0  1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19 

Record  1  0  0  0  0  1  7  0010 

Record  2  000021  0003 

Record  3  000040  0105 

Record  200  0  1  3  4  0  5  0216 

END  OF  FILE 

The  table  above  Illustrates  vhat  such  a  file  might  look  like  printed  out. 

The  lowest  numbered  product  code  is  17  with  a  unit  price  of  $10.  The  highest 
numbered  code  is  13405  with  a  unit  price  of  $216. 

The  Inventory  File 

The  Inventory  File  is  sorted  by  location  code  and  within  location  code  by 
product  number.  Thus  each  record  contains  the  quantity  and  total  value  of 
a  particular  product  on  hand  at  a  particular  location.  The  records  are 
30  character  records.  The  location  code  is  in  positions  0  through  5,  the 
product  code  number  In  positions  7  through  13,  the  quantity  on  hand  in 
positions  12  through  17  and  the  total  value  in  positions  19  through  28. 

The  following  table  shows  vhat  this  file  might  look  like  in  printed  report: 

INVENTORY  FILE 


Location 

Product 

On  Hand 

Value 

1 

17 

60 

600 

1 

21 

3006 

9016 

2 

17 

•  •  • 

80 

800 

2 

4o 

8 

840 

31 

17 

101 

1010 

31 

40 

7 

735 

31 

13405 

•  •  • 

2 

432 
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Bw  Transaction  pile 


The  Transaction  File  conalsts  of  reports  received  daily  froc  the  various 
locations ,  Each  reflects  an  Inventory  change  at  that  location  with  respect 
co  tame  product.  The  change  say  represent  either  an  increase  or  a  decrease 
in  the  number  of  units  on  hand.  There  may  be  sure  than  one  transaction  at 
a  location  for  a  particular  product.  Of  course,  there  will  be  products  for 
which  no  transaction  occurred  on  any  particular  reporting  day.  The  Transaction 
File  contains  20  character  records  and  is  unsorted.  It  has  the  following 
fields: 


Positions 
0  through  5 
7  through  10 
12 

13  through  17 


Contents 

Location  Code 

Product  Code  Number 

♦  for  accession  or  -  for  depletion 

Units  lost  or  gained 


Strategy 

smMPMMSnm 

The  Transection  File  is  first  switched  against  the  Product  File  in  order  to 
-alculete  the  value  change  resulting  from  the  units  lost  cer  gained.  The 
xnssctlon  File  la  sorted  on  the  product  code  number  field  which  puts  it  in 
-he  same  order  as  the  Product  File.  Both  of  these  files  are  input®  to  the 
r.ert  process  where  each  transaction  is  matched  with  a  product.  The  number  01s 
u-*its  last  or  gelnwd  from  the  Transaction  File  la  multiplied  by  the  unit  price 
frcm  the  Inventory  File.  The  product  is  stored  in  memory  following  the  units 
lost  or  gained  field  sad  an  output  record  is  written  containing  the  transaction 
information  plus  the  computed  value  information.  This  new  'lie  la  then  sorted 
by  product  within  location  to  put  in  the  same  relative  order  as  the  Inventory 
File.  An  updated  Inventory  File  is  now  produced.  Where  no  transactions  have 
occurred  the  old  record  la  copied.  Where  transactions  have  occurred  with 
respect  to  existing  inventory  records,  the  inventory  is  modified  by  the  units 
lost  or  gained  and  by  the  total  vnlue  lost  or  gained.  Where  s  transaction 
occurs  wheis  there  was  no  corresponding  record  in  the  old  fil''- -representing 
a  new  product  for  the  location- -a  new  record  is  generated.  No  attempt  is  made 
here,  aa  It  would  be  in  real  life,  to  verify  inputs  to  avoid,  for  example, 
ending  up  with  a  negative  quantity  on  hand. 


File  Configuration 

It  is  assumed  that  the  machine  being  used  has  available  six  tope  units.  Units 
1-4  are  required  for  sorting  and  any  tape  other  than  the  one  being  sorted  vould 
be  destroyed  if  mounted  on  one  of  these  units  during  the  sort.  To  avoid  this 
the  Product  File  tape  -3  mounted  on  Unit  5  and  the  Inventory  File  on  Unit  6.  The 
Transaction  File,  which  is  to  be  superseded  in  any  case  Is  mounted  on  Unit  2. 
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Notes  on  the  Language 

The  MADAM  Language  is  largely  self-explanatory.  Certain  points,  however,  will 
help  the  reader  follow  the  code. 

a.  Brackets  consisting  of  two  pairs  of  asterisks  mark  comments  which  are  not 
translated.  The  e^ierienced  user  seldom  employs  thee,  unless,  as  in  this 
case,  he  wishes  someone  else  to  understand  his  specifications  quickly. 

b.  A  MADAM  specification  begins  with  a  command  (here  only  SORT  and  ABSTRACT 
occur),  and  ends  with  the  term  END. 

c.  Following  the  Command  is  the  file  specification,  output  first,  then  inputs. 
Each  file  is  specified  by  a  file  number,  unit  number  pair,  e.g.,  ABSTRACT 

1,2  1,3  1,5* 

This  specifies  that  the  output  is  file  one  of  unit  two  and  the  two  inputs 
are  the  first  files  of  units  three  and  five.  The  READ  instruction  specifies 
the  particular  input  by  its  form,  READ  for  the  first  input  declared  and 
READB  for  the  second.  The  first  input  is  read  into  region  IN,  the  second 
into  region  INB. 

d.  When  an  IF  statement  is  true,  the  instruction  immediately  following  is 
executed.  When  it  is  false  the  next  labelled  instruction  is  executed. 

me  Job 

Here,  then,  is  a  set  of  MADAM  specifications,  four  in  all,  which  constitute  a 
Job,  the  Job  being  to  update  the  Inventory  File  from  the  daily  transactions. 

♦♦INVENTORY  UPDATE** 

♦♦MATCH  TRANSACTION  TO  PRODUCT** 

SORT  **TRANS.  FILE**  1,2 

BY  **KEY,  PRODUCT  NUMBER**  7,k 

♦♦MAXIMUM  RECORD  SI2:**  20 

END 


♦♦OBTAIN  VALUE  CHANGE  AND  GENERATE 


NEW  TRANSACTION  FILE** 
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ABSTRACT  **NEW  TRANS  FILE**  1,3 
♦♦INPUT  1,  PRODUCT  FILE**  1,5 
** INPUT  2,  TRANS  FILE**  1,2 

READ  **PRCDUCT  RECORD** 

1.  READB  **TRANSACTICN  RECORD** 

2.  IF  IN  0,4  LS  INB  7,^  **N0  MATCH** 

READ  **NEXT  PRODUCT  RECORD** 

DO  2  **TRY  MATCH  AGAIN** 

3.  COMPUTE  INB  13,5  *  IN  5,6 

**  UNITS  CHANGE  TIMES  UNIT  VALUE  ** 

«  INB  19,10  **  TOTAL  VALUE  FIELD  ** 

WRITE  INB  0,30  **  AUGMENTED  RECORD  ** 

DO  1  **  FETCH  NEXT  TRANSACTION  ** 

END 

(Note  that  process  terminates  automatically  vhen  end  of 
file  is  read  on  either  input.) 

**  MATCH  NEW  TRANSACTION  FILE  AGAINST 
INVENTORY  FII£  ** 

SORT  **  NEW  TRANS  FILE  **  1,3 
BY  **  MAJOR  KEY,  LOCATION  **  0,6 
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AND  **  MINOR  KEY,  PRODUCT  **  7,4 
**  MAX  RECORD  SIZE  **  30 
END 

**  PRODUCE  UPDATED  INVENTORY  +* 

ABSTRACT  **  NEW  INVENTORY  **  1,2 
**  INPUT  1,  OLD  INV.  #*  1,6 
**  INPUT  2,  NEW  TRANS  **  1,3 

READ  **  INVENT.  RECORD  ** 

READB  **  TRANS  RECORD  *# 

IF  ENDB  **  NO  MORE  TRANS  **  DO  REST 

IF  IN  0,6  LS  INB  0,6  **  NOT  THIS  LOCATION  ** 

OR  IN  7,4  LS  INB  7,4  **  NOT  THIS  PRODUCT  ** 

WRITE  IN  0,30  **  COPY  OLD  RECORD  ** 

READ  **  NEXT  INV  RECORD  **  DO  2 

IF  IN  0,6  GR  INB  0,6  **  next  LOCATION  ** 

OP  IN  7,4  GR  INB  7,4  **  NEXT  PRODUCT  ** 

WRITE  INB  0,30  **  NEW  ENTRY  **  DO  1 
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4.  #*  RECORDS  MLTST  MATCH  ** 

IF  IHB  18,1  EQ  (-)  **  UNITS  LOOT  ** 

COMPUTE  IN  12,6  -  INB  13,5  -  IN  12,6  **  UNITS  ** 
COMPUTE  IN  19,10  -  INB  19,10  -  IN  19,10  **  VALUE  ** 
WRITE  IN  0,30 
DO  1  **  GET  NEXT  TRANS  ** 


5-  **  THIS  IS  A  GAIN  ** 

COMPUTE  IN  12,6  +  INB  13,5  -  IN  12,6 
COMPUTE  IN  19,10  +  INB  19,10  •  IN  19,10 
WRITE  IN  0,30 
DO  1 


REST. 


Slim  and  Trim 


**  COPY  PART  OF  OLD  INV  NOT  REPRESENTED 
IN  TRANS  FILE  ** 

WRITE  IN  0,30  **  CURRENT  RECORD  ** 

READ  **  next  INV  RECORD  ** 

DO  REST  **  CONTINUE  TO  END  OF  FILE  ** 
END 


Imiit  the  casual  observer  should  think  the  above  specification  sat  Is  Iona  and 
laborious,  I  have  reproduced  the  same  Instructions  below  without  the  oomsntary. 

SORT  1,2  BY  7,4,20  END 


ABSTRACT  1,3  1,5  1,2 


READ 
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1.  READS 

2.  IF  IN  0,4  LS  INB  7,4  READ  DO  2 

3*  COMRJTE  INB  13,5  *  IN  5,6  «  INB  19,10 
WRITE  INB  0,30  DO  1  END 

SORT  1,3  BY  0,6  AND  7,4,30  END 
ABSTRACT  1,2  1,6  1,3 
READ 

1.  READB  IF  ENDB  DO  REST 

2.  IF  IN  0,6  LS  INB  0,6  OR  IN  7,4  LS  INB  7,4 

WRITE  IN  0,30  READ  DO  2 

3-  IF  IN  0,6  GR  INB  0,6  OR  IN  7,4  GR  INB  7,4 
WRITE  INB  0,30  DO  1 
4.  IF  INB  12,1  EQ  (-) 

COMPUTE  IN  12,6  -  INB  13,5  *  iff  12,6 
CCWPUTE  IN  19,10  -  INB  19,10  «  IN  19,10 
WRITE  IN  0,30  DO  1 

5-  COMPUTE  IN  12,6  +  INB  13,5  .  in  12,6 
COMPUTE  IN  19,10  +  inb  19,10  „  m  19>1Q 
WRITE  IN  0,30  DO  1 
REST.  WRITE  IN  0,30  READ  DO 


REST  END 
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